home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 691 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.3 KB

  1. Path: chronicle.mti.sgi.com!austern
  2. From: "Eugene Radchenko" <eugene@qsar.chem.msu.su>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Anyone considered inheritable friendship?
  5. Date: 12 Mar 1996 20:18:11 PST
  6. Organization: Lab. of Org.Synth., MSU
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <AFwV3Hn027@qsar.chem.msu.su>
  9. References: <4fnrfr$7b1@engnews1.Eng.Sun.COM>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: Mon, 11 Mar 1996 17:26:02 +0300 (MSK)
  12. X-Mailer: dMail [Demos Mail for DOS v1.23]
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBVAwUBMUZMlUy4NqrwXLNJAQHRQQIAxe/Zux3AjyjyuCt1HiPgz7LJ7dP5tcTG
  15.     SecfcZIY5MJdjkwKMtGiRstp43Yf2MvsM/3J/Zw9QluRtr4UonWD2Q==
  16.     =cR+Y
  17. Originator: austern@isolde.mti.sgi.com
  18.  
  19. clamage@Eng.Sun.COM (Steve Clamage) writes:
  20. >In article AFVop7nqs7@qsar.chem.msu.su, "Eugene Radchenko" <eugene@qsar.chem.msu.su> writes:
  21. [...]
  22. >>I think we should allow inheritable friendship (probably in addition to
  23. >>current non-inheritable one). Anyway, we are not creating the Pentagon
  24. >>security system and thus should not be much afraid of deriving Spy from
  25. >>TrustedUser. Especially considering that otherwise all ends in making this
  26. >>data public.
  27. >
  28. >I don't see much difference between allowing friendship to be inherited
  29. >and making all class members public. The purpose of access control is
  30. >not to hide implementation details from other programmers, because it
  31. >does not do that. The purpose is more to prevent other parts of the
  32. >program from depending on implementations details as opposed to depending
  33. >only on the public interface.
  34. >
  35. >If friendship is inheritable, you cannot know what functions have access to
  36. >the implementation details of the class. That means that you cannot change
  37. >those details. You might as well make everything public. The effect on
  38. >program design and maintenance is comparable.
  39.  
  40. But it is not. Inheritable friendship is a natural extension of normal
  41. friendship (for tightly coupled classes) to tightly coupled hierarchies.
  42. One possible example is the streambuf/iostreams hierarchies.
  43. In my project (that spawned the question) base class builds a certain graph
  44. and derived classes decompose it in different ways using helper objects
  45. from other hierarchies. Nobody except those objects (and original
  46. object tree, of course) has any business to that graph.
  47.  
  48.                Best regards                      Genie
  49.  
  50. --
  51. -----------------------------------------------------------------------
  52. Eugene V. Radchenko              Research associate, Computer Chemistry
  53. E-mail: eugene@qsar.chem.msu.su                   Fax: +7-(095)939-0290 
  54. Ordinary mail:     Chair of Organic Chemistry, Department of Chemistry,
  55.                          Moscow State University, 119899 Moscow, Russia
  56. -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  57.  I don't think anyone on the C++ standards committee believes that all
  58.  C++ programs should be strictly conforming.
  59.                            Fergus Henderson, moderator of comp.std.c++
  60. ---
  61. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  62.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  63.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  64.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  65.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  66. ]
  67.